-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Small systemd hardening #171
Conversation
@@ -0,0 +1,6 @@ | |||
[Manager] | |||
DumpCore=no |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
This can also be set by kernel command line. Better to set by config or append the already super long kernel command line?
-
Please add a link to the related systemd documentation.
-
Please add to readme.
-
Please undo in debug-misc package and add to readme there.
These are all the steps that I would have to do otherwise. I might some day but could be considerably delayed until I get to that.
## Allow no non-native calls as these may be used to circumvent some security protections | ||
## For example 32 bit x86 code is executable in modern 64 bit x86 systems because of backwards | ||
## compatibility. This is undesirable and can potentially be dangerous. | ||
SystemCallArchitectures=native |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems high potential for breakage. Do I have specific examples? No. But I have an approach for such situations...
Could you please suggest changing the default upstream at systemd instead? That would probably result in valuable insights if this is useful, why it's not the upstream default and/or what breakage to expect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems high potential for breakage. Do I have specific examples? No. But I have an approach for such situations...
Very big no. On a daily basis, you would rarely ever execute something of another architecture. For the most part, you can't anyway. For some, like 32 bit x86, you can do it because of backwards compatibility. But there aren't 32 bit x86 binaries on your 64 bit system anyway. This does not happen normally. x86 64 bit has been the industry standard for more than 20 years. Now, almost no operating system, even including the various linux distros, supports the 32 bit architecture, let alone the invidiual pieces of software. It bring no benefit to be able to execute those.
Other than that, there aren't any other use cases of supporting non native architectures, far as I know.
To be honest, since this never ever occurs, it also brings not too much extra security, because you won't make non native calls anyway. But it also brings no harm, IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. Please add to readme too.
Very little benefits that don't compensate the added complexity, so closing. |
Just allow native architecture calls. From what I understand, 32 bit binaries would not benefit from ASLR due to the incredibly small address space and might cause other programs to have less effective ASLR too. Apparently this can also cause other security issues and it is in general recommended not to execute anything non-native.
Also once again core dump.